Version 0 and 1 can have some content after SliceContent #112
Conversation
JeromeMartinez
force-pushed
the
Reserved
branch
from
5de92f1
to
d6717c6
Compare
|
the patch was made before #110 (comment) comment, let me know if "SHOULD" should be replaced by "MUST". IMO "SHOULD" is better here as there may be a good reason e.g. for checking CRC with "./ffmpeg -f lavfi -i mandelbrot -t 1 -c ffv1 -slicecrc 1 a.mkv" (current FFmpeg), but I am not strongly against using "MUST", priority is that files created this way are not considered invalid by the spec. IETF meaning of "SHOULD": "there may exist valid reasons in particular circumstances to ignore a particular item" |
|
I dont think extensibility and sequential decodability should be or are exclusive. |
|
You speak of version 3+, right?
This is my concern: if we add new fields, we break the idea of being backward compatible with older decoders which fallback to sequential decoding when a frame is corrupted, and IMO this is not good. I remember I asked some time ago about the capability to decode sequentially, and the current spec permits that. We should not break decoders, even if they are old and handle "new" v3 streams, else we'll break the trust in the format. Permitting new fields after data should be planned in v4, if necessary, by showing how new fields are introduces without breaking compatibility. Else we need to explicitly indicate that a new micro_version has an impact on sequential decoding (I will be against this change for v3, as v3 sequential decoders are already in the wild and micro_version is not tested for knowing if sequential decoding is possible, as it was not indicated in the draft; this is a draft, true, but this item was already discussed, so I don't see a good reason to break the idea). Anyway, this PR is for v0/v1, and here this is different (no slices, and frame byte size is provided by external method), so doable without risks. I suggest to merge the PR for v0/v1, then we debate separately about v3 (this PR does not touch on v3 so it introduces no change on it) |
From the debate in #110, I propose a different method for avoiding to have streams created by
"ffmpeg -c ffv1 -level 1 -slicecrc 1considered as non conforming to specification.This patch synchronizes specification with behavior of the decoder (which ignores the extra bits) by permitting the extra bits. It also add a note for people who would revise the specification about the risk of using 40 bits of the reserved part.
This patch does not prevent us to change our mind about #110 in the future.
Additional note: the extra bits are authorized only for versions 0 and 1 due to the existence of such bistream (not expected, but they are there) in the wild. "feature" of not having extra bits in version 3 is used by some decoders for being able to decode first slices (when latest bytes of a frame are missing, FFmpeg decoder decodes only the first slice, my own decoder uses the lack of reserved bits in the bitstream for parsing all slices up to the missing bytes by starting from the beginning and parsing all slices sequentially).